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Scope 



The present document describes interactions between ITU-T Recommendation H.323 [13] Terminals, Gatekeepers, 
Gateways and Switched-Circuit Networks (SCN) for support of TIPHON scenario 1 and scenario 2 
(see TR 101 307 [20]). 

The present document specifies a profile to be applied to the ITU-T Recommendation H.323 [13] for the purposes of 
TIPHON compliant systems. 

Call trace protocols, e.g. for use in tracing malicious calls, are outside the scope of the present document. 

The present document is applicable to Basic Calls and Inter-Domain Calls for voice only telephone calls: 

from H.323 Terminals on networks using Internet Protocol (IP) transport to Terminals on SCNs, e.g. Public 
Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN) or GSM Public Land Mobile 
Network (PLMN); and 

from Terminals on SCNs to H.323 Terminals on networks using IP transport. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in the ETSI Directives and the following 
apply: 

access token: octet string which may be present in Registration, Admission, and Status (RAS) messages and the Setup 
message. It is used to specify the identity, authorization, or other security characteristics of a network element or a user 

call: see "telephone call" 

endpoint: H.323 Terminal or Gateway. An endpoint can call and be called. It generates and/or terminates information 

streams 

Gatekeeper: gatekeeper is an H.323 entity on the network that provides address translation and controls access to the 
network for H.323 Terminals and Gateways. The Gatekeeper may also provide other services to the H.323 Terminals 
and Gateways such as bandwidth management and locating Gateways 

Gateway: H.323 Gateway is an endpoint on the network which provides for real-time, two-way communications 
between H.323 Terminals on the packet based network and other Terminals on a switched circuit network 
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H.323 Terminal: entity which provides audio and optionally video and data communications capability in 
point-to-point or multipoint conferences in packet-based networks 

telephone call: two-way speech communication between two users by means of Terminals via network infrastructure 



3.2 



Abbreviations 



In addition to the abbreviations explained in TR 101 307 [20] and TS 101 313 [21], the following abbreviaitons apply: 

ACF AdmissionConfirm (RAS message) 

ARJ AdmissionReject (RAS message) 

ARQ AdmissionRequest (RAS message) 

CLI Calling Line Identification 

CLIP Calling Line Identification Presentation 

DRC Direct Routed Call 

DSS1 Digital Subscriber Signalling System No. one 

DTMF Dual-Tone Multi-Frequency 

GCF GatekeeperConfirmation (RAS message) 

GRC Gatekeeper Routed Call 

IAM Initial Address Message [16] 

IN Intelligent Network 

IP Internet Protocol 

ISDN Integrated Services Digital Network 

ISUP ISDN User Part (of CCITT number 7 signalling) 

LCF LocationRequest (RAS message) 

LRJ LocationReject (RAS message) 

LRQ LocationRequest (RAS message) 

NNI Network-to-Network Interface 

PLMN GSM Public Land Mobile Network 

PINX Private Integrated services Network eXchange 

PSTN Public Switched Telephone Network 

RAS Registration, Admission, and Status 

RCF RegistrationConfirm (RAS message) 

RRQ RegistrationRequest (RAS message) 

SCN Switched-Circuit Network 

UNI User-to-Network Interface 

ZCF ZonelnformationConfirmation (RAS message) 

ZRQ ZonelnformationRequest (RAS message) 

4 Entities participating in the setup of a basic call 

The TIPHON system is a multi-component system. It consists of H.323 Terminals, Gateways, and Gatekeepers. 
For more details about these entitites and the scenarios in which they are acting refer to TS 101 313 [21]. 



Registration, call setup and call release 



5.1 



Overview 



The procedures of ITU-T Recommendations H.323 [13], H.225.0 [9] and H.245 [11] shall apply with the limitations or 
extensions described in this specification. The procedures of ITU-T Recommendation H.235 [10] shall apply 
unchanged. 

In accordance with ITU-T Recommendation H.323 [13], the protocol defined in ITU-T Recommendation H.225.0 [9] 
and the protocol defined in ITU-T Recommendation H.245 [11] shall be used for call control signalling and logical 
channel controlling within the packet based data network. The use of ITU-T Recommendations H.225.0 [9] and 
H.245 [11] is specified in more detail in the following subclauses. 
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NOTE: ITU-T Recommendation H. 225.0 [9] defines two protocols: Registration, Admission, and Status (RAS) 
and a ITU-T Recommendation Q.931 [22] -like protocol. 

Annex A describes changes to the ITU-T Recommendation Q.93 1 [22] messages and the contents of messages carried 
by the User-to-user information element in ITU-T Recommendation H. 225.0 [9]. 

The RAS protocol shall apply unchanged. 

The ASN.l definitions given in annex H of ITU-T Recommendation H. 225.0 [9] shall be used. 

The precise translation of ITU-T Recommendation H.323 [13] messages to the SCN and vice versa shall depend on the 
nature of the SCN (an ISDN, a PSTN, etc.) and the level of connectivity to be supported. This translation shall provide 
support, as necessary, of: 

the semantics of the protocol specified in ITU-T Recommendations Q.761 [15], Q.762 [16], Q.763 [17] and 
Q.764 [18] with variations in implementation appropriate to the region in which the SCN operates; or 

the semantics of the protocol specified in ITU-T Recommendation Q.931 [22] with variations in implementation 
appropriate to the region in which the SCN operates; or 

- the protocol specified in ISO/IEC 1 1572 [8]. 



5.2 Security principles 



If security services are required, TIPHON compliant systems shall support the security profiles defined in 
TS 101 323 [1]. Security services are not required always to be activated. 

5.3 Registration 

5.3.1 Registration basics 

Both H.323 Terminals and Gateways shall register with Gatekeepers. Registration shall be in accordance with ITU-T 
Recommendation H.323 [13] procedures. TIPHON compliant endpoints shall use Automatic Gatekeeper Discovery. The 
Gatekeeper shall convey information about as many alternate Gatekeepers as possible within security considerations, 
using the alternateGatekeepers field in the GatekeeperConfirmation (GCF) message. 

NOTE: Gateway performance may be enhanced if the Gatekeeper issues the PreGrantedARQ indication in the 
Registration Confirm (RAS message) (RCF) message on successful registration of the Gateway. 

Two types of registration shall be supported: 

authenticated registration with the Gatekeeper; 

anonymous registration with the Gatekeeper. 

5.3.2 Authenticated Registration 

Authenticated Registrations shall be in accordance with the security profiles in TS 101 323 [1]. 

5.3.3 Anonymous Registration 

In this case the RegistrationRequest (RAS message) (RRQ) message shall not contain an access token. This type of 
registration shall be used only for calls from an H.323 Terminal to a terminal in an SCN. 

NOTE 1: The intention here is to allow certain types of call, e.g. Freephone. The types of call are service provider 
dependent. 

NOTE 2: Within the H.323 zone all calls from a terminal in an SCN to an H.323 Terminal are initiated by the 

Gateway, which always does authenticated registration. Nevertheless certain services like Freephone may 
be provided by an SCN operator. 
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5.3.4 Registration Keep Alive 



Endpoints shall support the keep alive procedure as specified in subclauses 7.2.2 and 8.4.2 of 

ITU-T Recommendation H.323 [13]. If the registration ceases to be valid (e.g. the connection between the 

H.323 Terminal and its Gatekeeper goes down for some reason), the Gatekeeper shall remove the registration and 

release all ongoing calls associated with that terminal. A new registration may be established using the procedures of 

subclause 5.2.2 of ITU-T Recommendation H.323 [13]. 

5.4 Call setup 

5.4.1 Prerequisites 

Calls between users in the Internet Protocol (IP) network and users in the SCN shall be setup only after successful 
registration according to subclause 5.3. 

The sequences in annex B are built on the principles described in the following subclauses. 

5.4.2 Calls from an H.323 Terminal to a terminal in an SCN 

5.4.2.1 The en-bloc procedure 

If a CALL PROC message is returned to the H.323 Terminal, the "Sending complete" information element shall be 
inserted, if not already there, in the SETUP message towards the next network element (e.g. next Gatekeeper or a 

Gateway). 

5.4.2.2 Overlap sending 

On receipt of a SETUP message with a Called party number which the Gatekeeper cannot determine to be complete, the 
Gatekeeper starts timer T302 (the value of timer T302 is specified in ITU-T Recommendation Q.931 [22]) and sends a 
SETUP ACKNOWLEDGE message back. 

The Gatekeeper shall restart timer T302 on the receipt of every INFORMATION message not containing a sending 
complete indication and containing the called party information element with at least one valid character. 

An example of how to use the Overlap sending procedure within the IP network is shown in annex B, subclause 1.1. 

NOTE: A Called party number can be regarded to be complete under the following conditions: 

if the Gatekeeper has the full knowledge about the Called party's numbering plan and can identify the 
number to be complete; 

if the SETUP message contains the Sending complete information element; 

if the canOverlapSend parameter is absent or set to FALSE; 

if the Called party number contains the '#' character as the last digit; or 

if the Called party is identified by means of a non E. 164 [23] number contained in the destinationlnfo 
parameter. 

5.4.2.3 Establishment of media channels 
5.4.2.3.1 Fast Connect procedure 

TIPHON-compliant systems shall use the Fast Connect procedure of ITU-T Recommendation H.323 [13], 
subclause 8.1.7. 

NOTE 1: This includes the capability to negotiate media channels using ITU-T Recommendation H.245 [11] or to 
fall back to ITU-T Recommendation H.245 [11] signalling at any time of the call. 

NOTE 2: This enables in-band information to be passed prior to call establishment. 
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5.4.2.3.2 Encapsulation of H.245 messages within H. 225.0 messages 

TIPHON-compliant systems shall support encapsulation of ITU-T Recommendation H.245 [11] messages within 
ITU-T Recommendation H. 225.0 [9] messages according to ITU-T Recommendation H.323 [13], subclause 8.2.1. 

NOTE: Encapsulation of ITU-T Recommendation H.245 [11] messages within ITU-T Recommendation 

H. 225.0 [9] is preferred to a separate ITU-T Recommendation H.245 [11] channel because of its greater 
efficiency. 

5.4.2.4 Basic call setup 

Calls shall be setup using the procedures defined in ITU-T Recommendation H.323 [13] with the following 
changes/clarifications: 

within the context of this specification, call setup shall use only one user channel towards the SCN. Calls 
requiring a number of user channels shall not be supported; 

the Gatekeeper and its Gateway shall support both the en-bloc and the overlap sending procedure. 

NOTE 1 : Annex B gives possible mappings of messages to and from the SCN for overlap sending with fast connect. 

If an element or a message not allowed to be used within the context of this specification is received, the receiver shall 
pass on, but otherwise ignore, the message or the element i.e. the receiver shall act as if the message or the element was 
not received. 

If a element is received with a value, not allowed within the context of this specification, the receiver shall, if the 
element is optional, pass on, but otherwise ignore, the element (act as if the element is not received) or if the element is 
mandatory act as if the default value was received. 

NOTE 2: The security policy of an operator's network or the security policy implemented in a network element may 
override the error handling as described above. 

5.4.2.5 In-band information 
5.4.2.5.1 During call setup 

If the Gateway, connected to SCN, receives a PROGRESS message (before an AEERTING message is received) or a 
CALL PROCEEDING message with the Progress indicator information element included from SCN, the Gateway shall 
send a PROGRESS message to the Gatekeeper. The message shall contain the received Progress information element. 

If the message received from SCN is the CALL PROCEEDING message and the CALL PROCEEDING message is not 
sent, the Gateway shall send a CALL PROCEEDING message. The message shall contain the Progress indicator 
information element. 

When the Gatekeeper receives a CALL PROCEEDING message with a Progress indicator element included the 
Gatekeeper shall (before transferring the CALL PROCEEDING message) stop any running call supervision timer and 
start timer T301. 

When the Gatekeeper receives a PROGRESS message (before an ALERTING message is received) with the progress 
indicator information element included (but no cause element, see subclause 5.4.2.5.2) the Gatekeeper shall (before 
transferring the PROGRESS message) stop any running call supervision timer and start timer T301. 

When the H.323 Terminal receives a CALL PROCEEDING message with a Progress indicator element included the 
H.323 Terminal shall stop any running call supervision timer and start timer T301. 

When an H.323 Terminal receives a PROGRESS message (before an ALERTING message is received) with a Progress 
indicator information element included (but no Cause information element is included, see subclause 5.4.2.5.2) the 
H.323 Terminal shall stop any running call supervision timer and start timer T301. 
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5.4.2.5.2 During release 



If the Gateway, connected to SCN, receives a progress indicator information element in a DISCONNECT message from 
SCN the Gateway shall send a PROGRESS message to the Gatekeeper. The message shall include both the Progress 
indicator information element and the received cause. 

NOTE: If the Gateway receives a PROGRESS message with a Cause information element and a Progress 
indicator element the message shall be sent "as received" towards the Gatekeeper. 

When the Gatekeeper receives a PROGRESS message with both the Progress indicator information element and the 
Cause information element included the Gatekeeper shall (before transferring the PROGRESS message) stop any 
running call supervision timer and start timer T.301. 

When the H.323 Terminal receives a PROGRESS message with both the Progress indicator information element and the 
Cause information element included the Gatekeeper stop any running call supervision and start timer T.301. 

5.4.2.6 Usage of Called party numbers translated by the Gatekeeper 

The ARQ message sent from the H.323 Terminal to the Gatekeeper contains information about the Called party number 
in the destinationlnfo and destExtraCalllnfo fields. The Gatekeeper possibly translates the Called party number he 
received from the H.323 Terminal to another number and additional information. 

In the Direct Routed Call (DRC) case the translated information is sent back to the H.323 Terminal in the ACF message 
using the destinationlnfo, destExtraCalllnfo, and remoteExtensionAddress fields. If these fields contain information, 
the H.323 Terminal shall use that information in the SETUP message to the other endpoint. The H.323 Terminal shall 
hide this information from being accessed by the user. If these fields are not found, the H.323 Terminal shall use the 
number sent in the ARQ message also for the SETUP message. If these fields are found, but contain only zero elements, 
the H.323 Terminal shall not send any destination information in the SETUP message. In this case, the Gatekeeper may 
supply any relevant routing information in tokens to hide it from the H.323 Terminal. 

If the network wishes to protect routing information from a possibly hacked H.323 Terminal, it shall use the Gatekeeper 
Routed Call (GRC) model with preGrantedARQ. 

5.4.3 Calls from a terminal in an SCN to an H.323 Terminal 

5.4.3.1 Locating a called H.323 Terminal 

If the Gateway receives a call from the SCN, the Gateway shall attempt to locate the called H.323 Terminal. 
The way the Gatekeeper may locate a H.323 Terminal is described in annex D. 

5.4.3.2 Overlap sending 

The Gatekeeper shall support overlap sending on the SCN interface. If the addressed H.323 endpoint supports it, the 
Gatekeeper may use overlap sending towards the endpoint. 

NOTE: If the SCN uses overlap sending, the Gateway or its Gatekeeper need to retain the digits received until the 
H.323 Terminal can be found. 

5.4.3.3 The en-bloc procedure 

Once the H.323 Terminal is located by the Gatekeeper en-bloc procedures shall be used. The Gateway (DRC case) or 
the Gatekeeper (GRC case) shall include the Sending complete information element towards the H.323 Terminal. 
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5.4.3.4 Establishment of media channels 

5.4.3.4.1 Fast Connect procedure 

TIPHON-compliant systems shall use the Fast Connect procedure of ITU-T Recommendation H.323 [13], 
subclause 8.1.7. 

NOTE 1: This includes the capability to negotiate media channels using ITU-T Recommendation H.245 [11] or to 
fall back to ITU-T Recommendation H.245 [11] signalling at any time of the call. 

NOTE 2: This enables in-band information to be passed prior to call establishment. 

5.4.3.4.2 Encapsulation of H.245 messages within H. 225.0 messages 

TIPHON-compliant systems shall support encapsulation of ITU-T Recommendation H.245 [11] messages within 
ITU-T Recommendation H. 225.0 [9] messages according to ITU-T Recommendation H.323 [13], subclause 8.2.1. 

NOTE: Encapsulation of ITU-T Recommendation H.245 [11] messages within ITU-T Recommendation 

H. 225.0 [9] is preferred to a separate ITU-T Recommendation H.245 [11] channel because of its greater 
efficiency. 

5.4.3.5 Ring control tone 

When the called H.323 Terminal responds with an ALERTING message the called H.323 Terminal's Gatekeeper may 
start the ringing tone towards the calling party. If the Gatekeeper starts the ringing tone, then the Gatekeeper shall 
include the Progress Indicator information element with the PI set to No. 8 "In-band information or an applicable pattern 
is available". 

If a Gateway receives an ALERTING message which does not include a Progress indicator information element, with 
the PI set to No. 8 "In-band information or an applicable pattern is available", the Gateway shall start the ringing tone. 

If an ALERTING message is received on a call to an SCN, the Gateway shall include the Progress indicator information 
element with the PI set to No. 8 "In-band information or an applicable pattern is available" if the information is not 
already indicated. 

5.4.3.6 Basic call setup 

Calls shall be setup using the procedures defined in ITU-T Recommendation H.323 [13] with the following 
changes/clarifications: 

within the context of this specification, call setup shall use only one user channel from the SCN. Calls requiring a 
number of user channels shall not be supported; 

the Gatekeeper and its Gateway shall support both the en-bloc and the overlap sending procedure. 

If an element or a message not allowed to be used within the context of this specification is received, the receiver shall 
pass on, but otherwise ignore, the message or the element i.e. the receiver shall act as if the message or the element was 
not received. 

If a element is received with a value, not allowed within the context of this specification, the receiver shall, if the 
element is optional, pass on, but otherwise ignore, the element (act as if the element is not received) or if the element is 
mandatory act as if the default value was received. 

NOTE 1 : The security policy of an operator's network or the security policy implemented in a network element may 
override the error handling as described above. 

When the fast Connect procedure is used, the Gatekeeper should set the media WaitForConnect parameter to TRUE 
before sending the SETUP message to the H.323 Terminal. 

The Gatekeeper should remove the fastStart parameter from any message, received from the H.323 Terminal, prior to 
the CONNECT message. 
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NOTE 2: As a subscription option, the Gatekeeper may allow activation of the media channel in one or both 
directions prior to the CONNECT message for certain trusted users or equipment. 

5.4.4 Interworking with Dual Tone Multi-Frequency (DTMF) signalling 

Transfer of the DTMF tones within the IP network shall be by means of the ITU-T Recommendation H.245 [11] 
message userlnputlndication. 

Information received from the H.323 Terminal in the userlnputlndication message shall be extracted from the 
userlnputlndication message and injected into the media stream by using DTMF tones. This shall be done by the 
Gateway connected to the SCN. 

DTMF tones received from the SCN shall be extracted from the media stream and encoded in userlnputlndication 

messages by the Gateway. 

NOTE: The userlnputlndication could be tunneled via the FACILITY message if necessary. 

5.4.5 Carrier selection 

Carrier selection shall be performed by transmitting the necessary information to the Gatekeeper and Gateway within the 
called party number field. This procedure shall not preclude overlap sending. 

5.5 Active phase 

5.5.1 General aspects 

On calls to the SCN the active phase of the call shall commence when the called party answers and the Gateway issues 
the Connect message as a result. On calls from the SCN the Gateway shall pass the answer indication to the SCN. 

Upon detection of failure of the call in the IP network, accounting and charging functions shall be informed. 

NOTE 1 : In order to detect call failures in the IP network, which affect accounting and charging functions, 

Gatekeepers should specify an irrFrequency value inside the AdmissionConfirm (RAS message) (ACF). 

Transfer of the DTMF tones shall be by means of the ITU-T Recommendation H.245 [11] message 
userlnputlndication. 

Information received from the H.323 Terminal in the userlnputlndication message shall be extracted from the 
userlnputlndication message and injected into the media stream by using DTMF tones. This shall be done by the 
Gateway connected to the SCN. 

DTMF tones received from the SCN shall be extracted from the media stream and encoded in userlnputlndication 

messages by the Gateway. 

NOTE 2: The userlnputlndication could be tunnelled via the FACILITY message if necessary. 

5.5.2 Exceptional cases during the active phase 

If the Gatekeeper detects a failure, the Gatekeeper shall initiate clearing of the call as described in subclause 5.6. 

If the Gateway detects a failure, the Gateway shall initiate clearing towards the SCN, and clear the call in the IP network 
as described in subclause 5.6. 

If the H.323 Terminal detects a failure, the H.323 Terminal shall initiate clearing of the call as described in 
subclause 5.6. 
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5.6 Call release 

Call release may be initiated by the H.323 Terminal, the Gateway (e.g. as a result of the terminal in the SCN initiating 
release), or the Gatekeeper. The reason for initiating call release may e.g. be normal disconnection of a call or a call 
failure. 

Message collisions shall be handled by H.323 Terminals, Gatekeepers and Gateways. 

NOTE: Message collision occurs when the endpoint and the Gateway initiate clearing at the same time. 



5.7 Calling Line Identification (CLI) 



CLI information may be provided by calling users and may be received by called users. When a user wishes to provide a 
calling number it shall be provided using the signalling elements described in ITU-T Recommendation H. 225.0 [9]. 

Users may provide a number using the optional Calling Party Number information element in the Setup message. 

NOTE: The procedures and protocols for handling these information elements may be defined in regional and 
national regulations and/or codes of practice. Wherever such requirements exist they may supercede the 
requirements expressed here. 

According to ITU-T Recommendation H. 225.0 [9] the number cannot have qualifications defined in accordance with 
octet 3a information (Presentation Indicator and Screening Indicator) as in tables 4 to 1 1 of 
ITU-T Recommendation Q.931 [22]. Accordingly in the absence of octet 3a information the calling party number 
information element shall be treated as if octet 3a contained the following values: 

"presentation allowed"; and 

"user-provided not screened". 

As a consequence of the above the Gateway shall not include the Calling party number IE in the SETUP message 
towards the IP network if the Calling party information, received from the SCN network, indicates a restriction. 
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Annex A (normative): 

Required support of H. 225.0 call control protocol 

ITU-T Recommendation H.323 [13] uses a call control protocol derived from ITU-T Recommendation Q.931 [22] 
which is specified in the ITU-T Recommendation H. 225.0 [9]. 

This annex defines a profile which is intended to clarify the use of ITU-T Recommendation H. 225.0 [9] in 
TIPHON-compliant systems. Whenever the contents of this annex are in conflict with ITU-T Recommendation 
H. 225.0 [9] this annex shall take precedence. 

The current version of the Q.931 part of ITU-T Recommendation H. 225.0 [9] includes a number of optional messages 
and information elements. The EN 300 403-1 [5] standard (ETSI DSS1) forbids some of the information elements which 
are optional in ITU-T Recommendation H. 225.0 [9], listed below. Gateways that interconnect with ETSI DSS1 
networks shall not send these information elements. 

Table A. 1 identifies changes to entries in table 4 of ITU-T Recommendation H. 225.0 [9]. 

The changes in the table shall apply to TIPHON Phase 2 systems. 

Table A.1 : Modification to ITU-T Recommendation H. 225.0 [9] 
Usage of Q.931 [22] and Q.932 [19] Messages 



Call Establishment Messages 


Transmit (M, CM) 


Receive and act on (M, CM) 


Call Proceeding 


M 


M 


Progress 


M 


M 


Setup Acknowledge 


M 


CM (see note 1 ) 








Miscellaneous Messages 






Information 


CM 


M 


NOTE 1 : Only mandatory if the H.323 Terminal indicates canOverlapSend in the Setup message. 
NOTE 2: M = mandatory, CM = conditionally mandatory. 



A.1 Message definitions 
A.1 .1 Alerting 

Table A.2 identifies changes to entries in table 5 of ITU-T Recommendation H.225.0 [9]. 

Table A.2: Modifications to ITU-T Recommendation H.225.0 [9] 
Usage of the Alerting message 



Information element 


H.225.0 status 


Length in H.225.0 


Signal 


F 


NA 


NOTE: F = forbidden. 



A. 1.2 Information 

Table A.3 identifies changes to entries in table 9 of ITU-T Recommendation H.225.0 [9]. 

Table A3: Modifications to ITU-T Recommendation H.225.0 [9] 
Usage of the Information message 



Information element 


H.225.0 status 


Length in H.225.0 


Signal 


F 


NA 
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A.1 .3 Release Complete 

Table A.4 identifies changes to entries in table 10 of ITU-T Recommendation H. 225.0 [9]. 

Table A.4: Modifications to ITU-T Recommendation H. 225.0 [9] 
Usage of the Release Complete message 



Information element 


H.225.0 status 


Length in H.225.0 


Signal 


F 


NA 



A. 1.4 Setup 

Table A.5 identifies changes to entries in table 11 of ITU-T Recommendation H.225.0 [9]. 

Table A.5: Modifications to ITU-T Recommendation H.225.0 [9] 
Usage of the Setup message 



Information element 


H.225.0 status 


Length in H.225.0 


Signal 


F 


NA 



A.1 .5 Setup Acknowledge 



The contents and semantics of a SETUP ACKNOWLEDGE message received from the network are defined in 

tables 3 to 16 of ITU-T Recommendation Q.931 [22] with the single modification that the Signal information element is 

not allowed. 
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Annex B (informative): 
Message flows for call setup 

B.1 Gatekeeper Routed Calls 

The signalling procedures, described in the following subclause, are based on the Gatekeeper routed model. 

B.1 .1 Calls to a terminal in an SCN 

Figure B.1 illustrates message flows for a call from an H.323 Terminal to a terminal in an SCN. The H.323 Terminal 
and the Gateway are registered to the same Gatekeeper; the fast connect procedure and overlap sending are used. 



H.323 Terminal 



Gatekeeper 



Gateway 



SCN 



(note 3) 




(note 3) 



Media channel from 



Call Proc 



(note 2) 

Setup_ 
GW to Terminal activated 




Call Proc 
Alerting/Progxe 



Alertjng/Prooxe 
Media channel in bbth directions activated 




Jnfpjrnation 

_Call_Proc_ 

Alerting/Progre 

Connect 



(note 4) 



NOTE 1 : This figure is given only for informative purposes and reflects ITU-T Recommendation Q.931 [22] cases 

only. 
NOTE 2: As soon as the Gatekeeper has received sufficient digits to route the call, it shall send Setup to the 

Gateway. 
NOTE 3: Information messages may be sent as a result of a user providing more information. 
NOTE 4: If the SCN has received sufficient digits to complete number analysis, Call Proceeding shall be sent 

instead of Setup Ack in response to Setup and the Information message(s) will be discarded. 
NOTE 5: It is assumed that registration of the H.323 Terminal is performed before the start of the entire message 

sequence. In addition, in this flow diagram the ARQ/ACF procedure between Gateway and Gatekeeper is 

not shown since preGrantedARQ is assumed. 

Figure B.1 : Fast call setup using overlap sending and Gatekeeper routed call model within a Zone 
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B.1 .2 Calls to an H.323 Terminal 

Figure B.2 illustrates message flows for a call to an H.323 terminal. The H.323 Terminal and the Gateway are registered 
to the same Gatekeeper; the fast connect procedure and overlap sending are used. 



SCN 



Gateway 



Gatekeeper 



H.323 Terminal 




(note 1) 



NOTE 1 : Despite the use of the fast connect procedure the activation of the media channel is delayed until the 
Connect message is received by the Gatekeeper. This is accomplished by the use of the 
mediaWaitForConnect parameter and the removal of fastStart parameters by the Gatekeeper as 
described in subclause 5.4.3.6. 

NOTE 2: This figure is given only for informative purposes and reflects ITU-T Recommendation Q.931 [22] cases 
only. 

Figure B.2: Fast call setup using overlap sending and Gatekeeper routed call model within a Zone 
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Annex C (informative): 
Basic call scenario definitions 

Scenario 2 calls in annex C are for further study. 



C.1 Successful calls 



A successful call is one in which the network receives the called address and routes the call to a network Terminal which 
can accept two way speech communication. The network signalling will normally have sent an Answer signal back from 
the terminating exchange. The generally understood meaning of this is that the calling user is able to speak to a user 
handling calls directed at the called address or to some automatic call answering device. The normal expectation is that 
the caller will be required to pay for such calls. 

In addition to the simple meaning above there are cases, notably associated with mobile telephones, where network 
operators send back an answer signal even though two way speech has not been established. The normal expectation is 
that the caller will be required to pay for such calls. 



C.2 Unsuccessful calls 



Unsuccessful calls do not reach the two way or one way speech condition which follows Answer. The reasons for this 
are for example: 

caller clears prior to ringing; 

caller clears prior to answer; 

called party is engaged on another call; 

called party is not accepting calls; 

called party does not answer; 

network congestion is encountered. 

In all of these cases the user is not offered the service associated with a successful call but there is no fault in the 
network. 



C.3 Call failures 



A call failure occurs when the network fails to complete a call and is therefore neither successful or unsuccessful. A call 
failure also occurs when an established call, whether or not answer has occurred, is broken down as a result of 
equipment failure. The normal expectation is that customers do not pay for calls after the point at which the fault is 
detected. 



C.4 Calling line Identification (CLI) 

Whilst the text in this clause deals with CLI from the perspective of Scenario 1, the principles contained in this clause 
shall apply also for Scenario 2. Specific requirements for Scenario 2 are given in subclause 5.7. 

The following subclauses deal with two kinds of calling line identity. The general purpose is to ensure that a CLI is 
available for use by the terminating network. 

At present, according to ITU-T Recommendation H.225.0 [9] there is no definition of a mechanism for withholding CLI 
information derived by authentication or given as a presentation number. The behaviour of a TIPHON Gateway is that 
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the presentation indicator is set to Presentation Allowed in the SETUP and Initial Address Message (IAM) messages. If 
a Gateway does not have any number as a result of authentication of the supplied presentation number, the network 
number alone is supplied. The presentation indicator for network number is set to Presentation Restricted. In the case 
where no network number is available for whatever reason the value of the indicator is set to Number not available due 
to inter- working. 

Thus when a user either supplies a presentation number or arranges for the network number to be displayed the relevant 
presentation indicators are set to presentation allowed. 

C.4.1 Presentation number 

If a user wants the called party to receive a presentation number it can be achieved by putting a suitable E164 number in 
the Calling party number parameter of the SETUP message If the calling user has a special arrangement with the service 
provider, as described in ETS 300 092-1 [2], The type of number field may be a "subscriber number", "national 
number" or "international number" as specified in ETS 300 092-1 [2] with code point values defined in 
subclause 4.5.10 of ETS 300 403-1 [5]. 

The Gatekeeper may use the number supplied by the H.323 Terminal as well as the identification of the user determined 
by the authentication process. If the number appears to be a valid one, the user is authorized to provide presentation 
numbers and the interface from the Gateway is an Network-to-Network Interface (NNI) the number can be forwarded to 
the public network as "User provided, verified, and passed". If the interface is a User-to-Network Interface (UNI) the 
number will be passed to the network in exactly the same form as it was supplied in the 

ITU-T Recommendation H. 225.0 [9] SETUP message. This number will be converted into a presentation number if the 
ISDN exchange allows the facility. 

There is another way of generating a CLI to send to the called party. The user need not provide a number in the calling 
party field instead the Gatekeeper accesses a presentation number database indexed by the identification derived from 
the authentication operation. If the connection forwards into the narrow-band network is (ISUP) the number may be 
passed as "user provided, verified, and passed". This behaviour is specified in the Stage 3 Description for CLIP in ISUP, 
ITU-T Recommendation Q.731.3 [14]. If the interface to the narrow-band network is a UNI the calling party field is 
passed on in the same form as it was supplied by the user. The range of CLI values which can be passed over such an 
interface will make verification by the public network impossible. The UNI should therefore be registered with the 
service provider as one which uses the special arrangement described in subclause 6.2 of the CLIR protocol 
specification, ETS 300 092-1 [2]. The consequence of this is that all calling numbers passed over this interface will be 
delivered as "User provided, not verified". 

Whichever way it is generated the calling number is passed over the network to the terminating exchange where it is 
passed to the called party. If the called party is connected using ISDN the calling number information is passed 
unchanged in accordance with ETS 300 403-1 [5]. For PSTN lines with the CLI display service the number is sent in 
accordance with ETS 300 659-1 [6] for on hook signalling. In ISDN the calling party number information element is 
passed on unchanged to the called party only if he subscribes to the CLIP service. In the case of an analogue with caller 
display the number is always delivered but the qualification, see below, of the calling number is not necessarily sent. 
This is because the qualification parameter is not in a normative part of the specification. Nevertheless the qualification 
type values are identical to the ISDN case, i.e.: 

00: User provided, not verified; 

01: User provided, verified, and passed; 

10: User provided, verified, and failed; 

1 1 : Network provided. 

Numbers in the category "00: User provided, not verified" convey the meaning that the recipient shall treat the number 
as unreliable. If the called party does not want to receive calls from uncertain numbers he need not answer the call. 
Where the interface from the Gateway is an NNI the and authentication allows it the number may be given as either 
verified and passed, for a limited range of presentation numbers. Since this range of uncertainty is already conveyed it is 
not necessary to generate a new category solely for internet use. There is no greater uncertainty about an internet 
telephony number than about one which is user provided, verified and failed. The issue of whether that extra information 
should be displayed on analogue display devices is a matter for national regulators. 
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C.4.2 Network number 

For a normal telephone call the Network number is usually the same as the calling party number. In some cases the caller 
will choose not to release that number to the called party, nevertheless the callers number is transmitted to the 
terminating exchange with an indicator that it is not to be released. Certain customer lines, such as emergency services, 
are provided with an override facility which allows the calling number to be released irrespective of the caller's 
preference. The protocol used and the means of display is a national matter. 

When a presentation number is provided either by the user or by a Gatekeeper the type of number is not set to network 
number unless the actual identity of the user is verified and can be treated with the same certainty as an equivalent fixed 
network calling number. The purpose of this subclause is to describe how to find a calling party number which can be 
used by law enforcement agencies in order to commence investigations in the same way as for a normal fixed network 
call. 

There are a number of different configurations which need to be considered but the main issue is that of trust. For the 
scheme to meet its objective there shall be trust between the parties involved in the call which is equivalent to that 
between network operators providing calling line identities in today's network. The configurations include: 

directly connected IP links to the Gateway provider; 

indirectly connected permanent IP links to the Gateway provider; 

dial-in links to the Gateway provider; 

dial-in links to an indirectly connected Gateway provider; 

connections where the other providers act only third parties conveying IP traffic as if via a private data switch. 



C.5 In-band information 



The SCN may provide in-band information before the CONNECT message is sent. In-band information can be sent in 
the form of tones or announcements. 

Some reasons for in-band information are as follows: 

information to the calling user that the SCN telephone is ringing; 

SCN wants to give information to the calling user about the progress of the call, e.g. "You have now dialled the 
police please disconnect or wait and the call will be set-up"; 

- progress tone is sent to avoid silence while routing over low speed routes; 

the called party number has changed and the new number is announced (changed number interception service); 
different types of interception services giving announcements; 
different types of interception services routing the call to an operator; 

- prompt the calling user for more information. This case applies for some Intelligent Network (IN) services and it 
takes place before the active phase. 

To allow in-band information from the SCN to be transported to the H.323 terminal, the audio channel may be set-up 
before the SETUP message is sent to the SCN. 

C.5.1 Call to operator/Non-chargeable calls 

If the user places a call to an operator who is connected to the SCN, or if the call is routed to an operator because of the 
invocation of a service, it might happen that the operator does not return a B-answer, i.e. there will be no CONNECT 
message sent from the SCN to the gateway. The reason for this behaviour is that the operator does not want to start 
charging. 
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C.5.2 IN Services 

The user shall be able to utilize IN services within the SCN. Some of the IN services are simple number translation 
services while other IN services require user interaction. 

When user interaction is required the IN node prompts the user, using in-band information, and the user answers, using 
DTMF tones. 

The IN node may operate in two different modes: 

answered mode, i.e. the IN node sends a B-answer towards the calling user and then continues with the 
interactive part; 

non-answered mode, i.e. the IN node requests the SCN to establish the voice channels in both directions and then 
continues with the interactive mode. 

The answered mode will be experienced by the Gateway as a normal call while the non-answered mode will be 
experienced as a progress indicator No. 8 'In-band information or appropriate pattern is available' in a CALL PROC or 
a PROGRESS message. 
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Annex D (informative): 

Call Signalling for calls from a terminal in an SCN to an 

H.323 Terminal 



D.1 Introduction 



Establishing calls from an H.323 Terminal to a terminal in an SCN raises a unique problem of addressing - the only 
mean of addressing a user on a basic terminal in an SCN is by the number associated with that terminal (i.e. its "SCN 
address"). In public SCN applications this is an E. 164 [23] number, and in private IP network to private SCN 
applications, this is a "private network number" and will be formatted according to ISO/IEC 1 1571 [7] or ETS 300 189 
[3]. 



Call Direction ■ 




Home 
Gatekeeper 



Ingress 
Gatekeeper 



Transit 
Gatekeeper 



Figure D.1 : Configuration for calls from a terminal in an SCN to an H.323 Terminal 

This has an interesting side effect, as the Ingress Gatekeeper shall resolve the IP address of the Terminal from an SCN 
number. The issue of SCN number to IP address resolution is complex, and is being developed in Working Group 4 and 
standard organizations outside ETSI (e.g. IETF, ITU-T WG16 WP2 Q.13). For private networks numbers however the 
conversion to an IP address is likely to be less complex and will depend on the implementation. 

The call signalling can be made generic enough to not require extra standardization for the special case of SCN number 
to IP resolution. 

NOTE: The Gateway and the H.323 Terminal are not aware of the back-end service(s) used by the Ingress 
Gatekeeper to resolve the SCN number into an IP address. 
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D.2 H.323 Terminal Registration 

As the Home Gatekeeper will be requested by Ingress Gatekeepers to locate the terminal using an SCN number, 
H.323 Terminals that wish to receive calls from terminals in SCNs need to register with their Gatekeeper an SCN 
number that is equal to their registered global SCN number (if applicable) or private network number. 

Home Gatekeeper IP-Terminal 

RRQ(999 123 456 789 012, name@email.net) 



-RCF- 



NOTE: This does not stop a H.323 Terminal from also registering an additional e-mail-like alias, or from 

registering some well-known ID that the Gatekeeper will recognize and transform into the Client's global 
code (and return it in the RCF message). 

Figure D.2: H.323 Terminal Registration for calls from a terminal in an SCN to an H.323 Terminal 



D.3 SCN number-IP Identification 

D.3.1 Identification by the Switch/Private Integrated Services 
Network Exchange (PINX) 

The main problem for the Switch/PINX is to recognize that a given SCN number could be resolved into the IP address 
of an H.323 Terminal, instead of that of a remote terminal in an SCN or a Gateway. This may be done by looking for a 
global prefix (e.g. +999), local prefix (e.g. *999) or other means. 

When the SCN number has been identified by the Switch/PINX as one assigned to IP, the Switch/PINX shall transfer the 
call to a Gateway (which may be collocated with the Switch/PINX). 

D.3. 2 Identification by the Ingress Gateway 

The Gateway has not explicit knowledge whether an incoming call from an SCN is addressing an H.323 Terminal or 
another Gateway - it receives a call from the SCN with some destination number, and attempts to locate a callable 
TIPHON endpoint (Gateway or Terminal) by contacting its Gatekeeper - it makes no difference from the gateway's 
perspective. 

D.3. 3 Identification by the Ingress Gatekeeper 

The Ingress Gatekeeper shall be able to recognize that the destination SCN number is that of an H.323 Terminal and not 
that of a terminal in an SCN. When recognizing the SCN number as that of an H.323 Terminal it shall consult some 
internal and/or external databases to find the address of the Home Gatekeeper of the owner of that SCN number. 

When the address of the Home Gatekeeper is found, 4 resolution methods could be used: 

the Ingress Gatekeeper may return an LocationReject (LRJ) (Redirect ""* Home Gatekeeper) message, which will 
cause the Gateway to reissue the LocationRequest (LRQ) message directly to the Home Gatekeeper; 

the Ingress Gatekeeper may issue an ITU-T Recommendation H. 225.0 annex G [9] AccessRequest to the Home 
Gatekeeper, and reply with the result to the Ingress Gateway 

the Ingress Gatekeeper may issue an ITU-T Recommendation H. 225.0 annex G [9] AccessRequest to the Home 
Gatekeeper, and reply with its own call-signalling address to facilitate a Gatekeeper-routed call; 
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both the Ingress Gateway and the Terminal may be registered with the same Gatekeeper, in which case the 
Gatekeeper does not have to perform any further queries or redirections. 



D.4 Message flows 



The following subclauses show the message flow for each possible sequence as described above. 



D.4.1 Direct/LRJ (Redirect) 



The following flow of messages shall be used to signal a call from a terminal in an SCN to an H.323 Terminal using the 
Direct/LRJ (Redirect) model: 



SCN Terminal Switch/PINX Gateway 



Gatekeeper 



DB 



"Call Setup^ 



LRQ 
(SCN Number)- 



LRJ _ 
-(H-GK) 



Lookup 
(SCN Number) & 
Answer . . 
I • • (H-GK) 



LRQ 
(SCN Number)- 

LCF 
'(IP-Address) 



Home-Gatekeeper IP-Terminal 



NOTE: The rest of the call is the same as for calls from an H.323 Terminal to a terminal in an SCN (e.g. 
ARQ/ACF, SETUP, etc.). 

Figure D.3: Message flow for a call from a terminal in an SCN to an 
H.323 Terminal: Direct/LRJ (Redirect) 



D.4. 2 Direct/Inter-Gatekeeper 



The following flow of messages shall be used to signal a call from a terminal in an SCN to an H.323 Terminal using the 
Direct/Inter-Gatekeeper model: 



SCN Terminal Switch/PINX 



Gateway 



Gatekeeper 



Home-Gatekeeper IP-Terminal 



"Call Setup . 



ARQ 
(SCN Number) - 



ACF 

-(IP-Address) 



Lookup 
(SCN Number)* 
Answer . . 
4 ■ ■ (H-GK) 

"Annex G AccessRequest 
(SCN Number) 

Annex G AccessConfirm ' 
(IP-Address) 



NOTE: The rest of the call is the same as for calls from an H.323 Terminal to a terminal in an SCN (e.g. 
ARQ/ACF, SETUP, etc.). 

Figure D.4: Message flow for calls from a terminal in an SCN to an 
H.323 Terminal: Direct/Inter-Gatekeeper 
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D.4.3 Gatekeeper-routed 



The following flow of messages shall be used to signal a call from a terminal in an SCN to an H.323 Terminal using the 
Gatekeeper-routed model: 



SCN Terminal Switch/PINX 



Gateway 



Gatekeeper 



Home-Gatekeeper IP-Terminal 



Call Setup _ 



ARQ 
(SCN Number)-^ . Lookup 

(SCN Number)-* 
Answer . . 
U - - (H-GKI 



ACF 
-(GK- Address) 



Annex G AccessRequest 
(SCN Number) 

Annex G AccessConfirm "" 
(H-GK-Address) 



NOTE 1 : In the message-flow above, both Gatekeepers route the call-control channel. It is also possible to have a 

mixed Direct-Routed/Gatekeeper-Routed at each side of the call. 
NOTE 2: The rest of the call is the same as for calls from an H.323 Terminal to a terminal in an SCN (e.g. 

ARQ/ACF, SETUP, etc.). 

Figure D.5: Message flow for calls from a terminal in an SCN to an 
H.323 Terminal: Gatekeeper-routed 



D.4.4 Local Scope 



The following flow of messages shall be used when both the Ingress Gateway and the H.323 Terminal are registered 
with the same Gatekeeper. Although an arguably rare case, this is still a possible scenario. 



SCN Terminal 



Switch/PINX 



Gateway 



Gatekeeper 



IP-Terminal 



"Call Setup _ 




ARQ 
(SCN number) - 

ACF(IP) 

Setup - 



"Setup- 



NOTE: The rest of the call is the same as for calls from an H.323 Terminal to a terminal in an SCN (e.g. 
ARQ/ACF, SETUP, etc.). 

Figure D.6: Message flow for calls from a terminal in an SCN to an 
H.323 Terminal: Local Scope 
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D.5 SCN Re-routing 



A special case exists when the current location of the user is returned by the Home Gatekeeper as an SCN number 
instead of a callable IP address. In this case the call may be returned to the Switch/PINX to be routed as a normal SCN 
call. Please note that ITU-T Recommendation H. 225.0 version 3 [9] supports the "RedirectToSCN" reject code. 



SCN Terminal 



Switch/PBX 



Gateway 



Call Setup 



Call Transfer 
4r(SCN number) 

Y 



Gatekeeper 



DB 



LRQ 

(SCN number) - 



LRJ 
• (Redirect to SCN) 



Home-Gatekeeper SCN-Terminal 



Lookup 
(SCN number) >; 
Answer . . 
4 " " (H-GK) 

" Annex G AccessRequest 
(SCN number) 

Annex G AccessConfirm 
(Alternate SCN number) 



NOTE: In this scenario the TIPHON network is being used as IN infrastructure for the SCN network. 

Figure D.7: Call flow for SCN Re-Routing 

D.6 H. 225.0 annex G as a Global-Code front-end 
Protocol 

Annex G of ITU-T Recommendation H. 225.0 [9] allows Gatekeepers to advertise SCN coverage. This allows 
Gatekeepers that cannot access an SCN-IP Database directly to request Gatekeepers that can to resolve the address on 
their behalf. It is also possible for the Global Code Gatekeeper itself to request the address of the terminal in the SCN 
from the Home Gatekeeper, which will result in the originating Gatekeeper receiving the address of that terminal 
directly from the Global Code Gatekeeper immediately (and not having to execute the reject/redirect sequence). This 
sequence does not require any special consideration, as it is already covered by the standard. 



SCN Terminal 



Switch/PINX 



Gateway 



Gatekeeper 



Call Setup . 



Global Code 
Gatekeeper 



ARQ 
(SCN number) - 



ACF 

-(IP-Address) 



~ZRQ_ 

ZCF . 
'(999') 



-AccessRequest 
(SCN number) i 




Lookup 
(SCN number) >: 
Answer . - 
I • • (H-GK) 



nex G AccessRequest 
(SCN number) 



A^nex G AccessConfirj 
(IP-Address) 



Home-Gatekeeper IP-Terminal 



Figure D.8: Call flow for Indirect Inter-Gatekeeper 
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